-
Notifications
You must be signed in to change notification settings - Fork 32
⚗️🎨 Add clearly identifyable container hostname ⚠️ #8215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
⚗️🎨 Add clearly identifyable container hostname ⚠️ #8215
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #8215 +/- ##
==========================================
+ Coverage 86.79% 88.09% +1.30%
==========================================
Files 1910 1910
Lines 73396 73396
Branches 1301 1301
==========================================
+ Hits 63704 64659 +955
+ Misses 9305 8350 -955
Partials 387 387
Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR adds service-specific prefixes to container hostnames for better identification and debugging purposes. Each service now has a clearly identifiable hostname that includes a short prefix followed by the node hostname and task slot.
- Adds abbreviated service prefixes to all container hostnames (e.g., "api-", "dv2-", "sw-")
- Maintains the existing Docker Swarm templating pattern with
{{.Node.Hostname}}-{{.Task.Slot}} - Improves debugging capabilities by making containers easily identifiable in logs and monitoring tools
You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a good reason for not using the entire service name instead of a shorthand? That would avoid potential guessing.
Yes sadly there is: docker hostnames have a maximum length (afaik 64chars), so there is a virtue in being short, in case the hostname of the machine might be long. Any container with a hostname >max_length will not start |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am very scarred of such a wide change.
Many of these services do not connect with the DB at all.
I am happy to do a PR to add the application name on top of the hostname directly when connecting to the DB via the postgres clients instead. Just let me know
I am actually not so scared of this change but if you prefer not to have it, or to make your proposed variant, this is fine for me :) |
|
|
Closing in favor of #8220 |



What do these changes do?
For every container adds a clearly identifiable hostname. This aids debugging, as it will show up e.g. in postgres-clients in adminer, etc.
Since the hostname is re-used in many places where it is not directly obvious (postgres-client names, potentially in rabbit connection etc.) there is a small but non-zero chance that this PR breaks some stuff. We can see on master.
Related issue/s
#8199
How to test
Dev-ops
Observe that container hostname on deployments is short enough (<64 chars, valid DNS FQDN)